home *** CD-ROM | disk | FTP | other *** search
- Path: solon.com!not-for-mail
- From: schwarz@mips.complang.tuwien.ac.at (Konrad Schwarz)
- Newsgroups: comp.lang.c,comp.lang.c.moderated,hp.unix,comp.sys.hp.apps,comp.sys.hp.hpux
- Subject: Re: C coding problem
- Date: 3 Apr 1996 18:59:09 -0600
- Organization: TU Wien
- Sender: clc@solutions.solon.com
- Approved: clc@solutions.solon.com
- Message-ID: <4jv6st$crf@solutions.solon.com>
- References: <4ianbf$h86@solutions.solon.com> <4iemcl$a05@solutions.solon.com> <4io1io$no4@solutions.solon.com> <4j06na$808@solutions.solon.com> <4jttan$3gf@solutions.solon.com>
- NNTP-Posting-Host: solutions.solon.com
-
- In article <4jttan$3gf@solutions.solon.com>, nsmart@indigo.ie (Niall Smart) writes:
- |>
- |> >: I recently wrote a loop that went like this:
- |>
- |> >: while (p < end_p)
- |> >: ++*p++;
- |>
- |> >: Maybe some will find it a counter-example; I think it's good
- |> >: code that embodies the way C is designed to work. Arrays are
- |> >: second rate objects in C. Use pointers.
- |>
- |> That code scores negative for maintainability, why use arcane
- |> features of the language that can be replaced with more readable code?
-
- My point is precisely that pointers should not be considered arcane.
-
- |> If you read any of the books on writing good code you will find
- |> hundreds of reasons to avoid code like that. The execution time you
- |> *might* be saving is offset many times by the time it takes a
- |> maintainer to figure it out.
-
- Execution time has nothing to do with it.
-
- |> Secondly, why not use arrays? In many places they are easier to
- |> understand - I for one am not going to compromise the readability
- |> of my programs because of some theoretical bull about them
- |> being second rate objects. (whatever that is intended to mean)
-
- You answer this question yourself below.
-
- |> a[i] is converted to *(a + i) by the compiler in any case so
- |> whats the advantage with your approach?
-
- The machine doesn't have to add, the machine doesn't have to multiply,
- *a is less complicated to understand than a [i] since only one variable
- is involved, *a is more type safe than a [i], since there is nothing
- constraining i (besides it being of integral type), the optimizer
- has less to do, compile time decreases, etc.
-
- Why use C if you're uncomfortable with pointer arithmetic? Why use
- functional languages if you're uncomfortable with recursion? Why use
- object-oriented languages if you're uncomfortable with objects?
-
- Konrad Schwarz
-